feat(settings): auto-publish cloud runs toggle in advanced settings by k11kirky · Pull Request #3217 · PostHog/code

k11kirky · 2026-07-07T09:52:19Z

Problem

Cloud runs are review-first by default: the sandbox agent stops with local changes and won't push or open a PR unless explicitly asked. For most users the PR is the deliverable of a cloud run, so this default costs an extra round trip on nearly every run. We want this to be user-configurable, and on by default.

Changes

New Settings → Advanced toggle "Always create pull requests for cloud runs" (autoPublishCloudRuns, default on, persisted).
The setting is threaded through task creation (cloudAutoPublish on TaskCreationInput → autoPublish run option → auto_publish in the run-creation request body), and carried across resume runs from the previous run's state like pr_authorship_mode.
agent-server accepts a new --autoPublish flag: when set, shouldAutoPublishCloudChanges() returns true for manual (non-Slack/signal) origins too, so the cloud system prompt switches to the push-and-open-a-draft-PR variant (including no-repository mode). --createPr false still disables publishing, and manual runs keep the "PostHog Code" PR attribution.

Requires the backend side to accept and forward the new field: PostHog/posthog#68864 adds auto_publish to the run-creation API and passes --autoPublish to the sandbox.

Warm-pool reuse at task creation skips run creation entirely, so auto_publish is also sent in the createTask payload for cloud creations; the backend persists it into the activated warm run's state so resumes honor the setting (PostHog/posthog#68864).
Prewarmed runs are handled too: their agent-server boots before the first message exists, so the launch flag can't carry the choice — but nothing is sent to the agent until the forwarded first message arrives. On that first message the server re-reads the run's state (where the backend persists auto_publish at warm activation), flips its config, and injects the auto-publish cloud instructions into the prompt as an override, reusing the existing prContext injection channel so both runtime adapters work unchanged. createPr=false still wins, automated origins are unaffected, and a failed state fetch retries on the next message. No boot latency is added — the extra run fetch happens at message time, only for prewarmed runs.

How did you test this?

turbo typecheck on shared/core/ui/api-client/agent — clean.
vitest full core suite and agent-server suite pass. New tests: auto-PR prompt for manual runs with autoPublish (incl. attribution), createPr=false still wins, no-repo mode variant, and saga threading of cloudAutoPublish → autoPublish.
Extended the warm-activation saga test to assert auto_publish rides on the createTask payload — catches the setting being silently dropped for prewarmed runs (the only request that reaches the backend in that flow).
New agent-server tests for the prewarmed upgrade: state with auto_publish upgrades the run (override injected once, config flip persists), state without it stays review-first, createPr=false blocks the upgrade without even fetching, and a failed state fetch retries on the next message. Full agent-server suite (91) passes.
Biome clean on changed files.

Automatic notifications

Publish to changelog?
Alert Sales and Marketing teams?

Created with PostHog Code

Adds a default-on "Always create pull requests for cloud runs" setting. When enabled, cloud task runs are created with auto_publish, and the sandbox agent-server (via the new --autoPublish flag) prompts the agent to push its work and open a draft PR on completion instead of stopping with local changes. Generated-By: PostHog Code Task-Id: 49d73463-ec66-491c-b645-f6116972bd02

trunk-io · 2026-07-07T09:52:23Z

Merging to main in this repository is managed by Trunk.

To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

github-actions · 2026-07-07T09:52:48Z

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit cecf237.}

greptile-apps · 2026-07-07T09:56:38Z

_{Reviews (1): Last reviewed commit: "feat(settings): auto-publish cloud runs ..." | Re-trigger Greptile}

greptile-apps · 2026-07-07T09:56:42Z

      delete process.env.POSTHOG_CODE_INTERACTION_ORIGIN;
    });

+    it("returns auto-PR prompt for manual runs when the user opted into auto-publish", () => {
+      const s = createServer({ autoPublish: true });
+      const prompt = (s as unknown as TestableServer).buildCloudSystemPrompt();
+      expect(prompt).toContain("gh pr create --draft");
+      expect(prompt).not.toContain("stop with local changes ready for review");
+      // Manual runs keep the PostHog Code attribution.
+      expect(prompt).toContain(
+        "Created with [PostHog Code](https://posthog.com/code?ref=pr)",
+      );
+    });
+
+    it("keeps review-first prompt when auto-publish is on but createPr is false", () => {
+      const s = createServer({ autoPublish: true, createPr: false });
+      const prompt = (s as unknown as TestableServer).buildCloudSystemPrompt();
+      expect(prompt).toContain("stop with local changes ready for review");
+      expect(prompt).not.toContain("gh pr create --draft");
+    });
+
+    it("auto-publishes in no-repository mode when the user opted in", () => {
+      const s = createServer({ repositoryPath: undefined, autoPublish: true });
+      const prompt = (s as unknown as TestableServer).buildCloudSystemPrompt();
+      expect(prompt).toContain("Cloud Task Execution — No Repository Mode");
+      expect(prompt).toContain("without waiting to be asked");
+      expect(prompt).not.toContain("unless the user explicitly asks for that");
+    });


Prefer parameterised tests for similar cases

The three new tests all exercise the autoPublish: true path and share a common assertion structure (checking for/against "gh pr create --draft" and "stop with local changes ready for review"). Tests 1 and 2 are especially close — they differ only in createPr: false and expected prompt content — and could be folded into an it.each block alongside the existing origin-based parameterised tests just below. The no-repo test (test 3) shares the "draft PR" assertion with test 1 and could similarly be grouped. Using it.each here would make the full matrix of (autoPublish, createPr, mode) behaviour easier to scan and extend.

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Inline the one-ternary getCloudAutoPublish helper, pass the option value through in the request body builder, take a single settings snapshot in useTaskCreation, and split the no-repo cloud prompt into per-mode blocks mirroring the repository branch. Generated-By: PostHog Code Task-Id: 49d73463-ec66-491c-b645-f6116972bd02

greptile-apps · 2026-07-07T11:14:48Z

_{Reviews (2): Last reviewed commit: "chore(settings): simplify auto-publish t..." | Re-trigger Greptile}

… carry it When task creation reuses a pre-warmed run, the saga skips run creation entirely — so the auto-publish choice, previously only sent on the run-creation request, never reached the backend for warm runs. Send auto_publish in the createTask payload for cloud creations; the backend persists it into the activated warm run's state so resumes honor it (PostHog/posthog#68864). Generated-By: PostHog Code Task-Id: 79bdd820-1678-48d9-a12b-922127eab1c1

…pgrade A prewarmed run's agent-server boots before the user's first message exists, so the --autoPublish launch flag can't carry the user's choice and the whole run stayed review-first. Nothing is sent to the agent until the forwarded first message arrives, so the choice can still govern the entire conversation: on that first message, prewarmed runs re-read the run's state (where the backend persists auto_publish at warm activation), flip the config, and inject the auto-publish cloud instructions into the prompt as an override — reusing buildCloudSystemPrompt and the existing prContext injection channel, so both runtime adapters work unchanged. createPr=false still wins (PostHog AI warm runs), automated origins already auto-publish, and a failed state fetch retries on the next message. Generated-By: PostHog Code Task-Id: 79bdd820-1678-48d9-a12b-922127eab1c1

Adds a persisted mobile setting (default on) that makes cloud runs push their changes and open a draft pull request on completion, matching the desktop advanced-settings toggle. The new-task composer sends the setting as `auto_publish` on the cloud run request; the backend already interprets it. Generated-By: PostHog Code Task-Id: f544ff52-3a2f-47fe-9dbd-c1299fe4b425

k11kirky mentioned this pull request Jul 7, 2026

feat(tasks): support auto_publish option on cloud task runs PostHog/posthog#68864

Merged

2 tasks

greptile-apps Bot reviewed Jul 7, 2026

View reviewed changes

k11kirky marked this pull request as ready for review July 7, 2026 11:11

tatoalo approved these changes Jul 7, 2026

View reviewed changes

k11kirky added 2 commits July 7, 2026 14:40

k11kirky merged commit 0f5a1d9 into main Jul 7, 2026
24 checks passed

k11kirky deleted the posthog-code/auto-publish-cloud-runs-setting branch July 7, 2026 17:03

Gilbert09 mentioned this pull request Jul 8, 2026

feat(mobile): auto-publish cloud runs toggle (port #3217) #3261

Merged

Gilbert09 added a commit that referenced this pull request Jul 8, 2026

feat(mobile): auto-publish cloud runs toggle (port #3217) (#3261)

e7cba13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(settings): auto-publish cloud runs toggle in advanced settings#3217

feat(settings): auto-publish cloud runs toggle in advanced settings#3217
k11kirky merged 4 commits into
mainfrom
posthog-code/auto-publish-cloud-runs-setting

k11kirky commented Jul 7, 2026 •

edited

Loading

Uh oh!

trunk-io Bot commented Jul 7, 2026

Uh oh!

github-actions Bot commented Jul 7, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Jul 7, 2026

Uh oh!

greptile-apps Bot Jul 7, 2026

Uh oh!

greptile-apps Bot commented Jul 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

k11kirky commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Changes

How did you test this?

Automatic notifications

Uh oh!

trunk-io Bot commented Jul 7, 2026

Uh oh!

github-actions Bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greptile-apps Bot commented Jul 7, 2026

Uh oh!

greptile-apps Bot Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot commented Jul 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

k11kirky commented Jul 7, 2026 •

edited

Loading

github-actions Bot commented Jul 7, 2026 •

edited

Loading